A: Non-repeating cases:

1: User A PUBLISHes an event

Was able to PUBLISH and process an event to/from all vendors

2: User A invites Users B, C, D & E to a meeting:

A: ATTACHments:

1: 0

Was able to send all vendors a single without attachments. One vendor accepted, but then vendor’s user became chair and sent out 20 rescheduled notice.

2: 1

Was able to send all vendors a single with one attachment (bmp).

3: 1+

Was able to send all vendors a single with two attachment

B: ALTREPs of:

1: DESCRIPTION

Was able to send all vendors a single with AltReps of text in the description field.

2: COMMENT

Was able to send all vendors a single with AltReps of text in the comments dialog.

4: LOCATION

Was able to send all vendors a single with AltReps of text in the location field.

C: Including ALARMS

1: AUDIO only

Was able to send all vendors a single with audio alarm.

2: DISPLAY only

Was able to send all vendors a single with display alarm

3: EMAIL only

Was able to send all vendors a single with email alarm.

F: ATTENDEE property parameters:

1: CUTYPE:

A: INDIVIDUAL (Default)

Was able to send to vendors individually

B: GROUP

Was able to send to GROUP of vendors

C: RESOURCE

D: ROOM

Was able to send all vendors a single Invite with an RnR.

3: ROLE:

A: CHAIR

Was able to send a single Invite with Chair role to all vendors.

B: REQ-PARTICIPANT (Default)

Was able to send a single Invite with REQ-PARTICIPANT role to all vendors.

C: OPT-PARTICIPANT

Was able to send a single Invite with OPT-PARTICIPANT role to all vendors.

4: PARTSTAT:

A: NEEDS-ACTION (Default)

Was able to send a single Invite with NEEDS-ACTION.

B: ACCEPTED

Was able to send an ACCEPTED out

C: DECLINED

Was able to send a DECLINED out

D: TENTATIVE

Was able to send a TENTATIVE out

5: RSVP

A: TRUE

Was able to send with RSVP=TRUE

B: FALSE (Default)

Was able to send with RSVP=FALSE

8: SENT-BY

B: 1

Was able to send a single event with SENT-BY.

9: CN

B: 1

Was able to send with a CN.

3: User B Accepts the invitation:

Sent two vendors a single. Two vendors can accept.

A: but then Declines the invitation

One of the vendor declines. The other vendor mentioned that iTips does not work for him yet, so he cannot accept then decline

4: User C Declines the invitation:

A: but then Accepts the invitation:

One vendor accepts. The other vendor mentioned that iTips does not work for him yet, so he cannot decline then accept

6: User E Delegates to User G:

A: User G Accepts the invitation:
B: User G Declines the invitation:
C: User G requests a Refresh of the invitation:
D: User G Counters with a new meeting time:
E: User G Delegates to User I:

Couldn’t test this scenario since it requires at least two other vendors which support delegation.

7: User A reschedules the meeting: Repeat permutations of 1-6 below as necessary.

B: Repeating cases:

(Repeat A. subcases but expand for instance manipulation including entire set, 1 instance, THISANDPRIOR & THISANDFUTURE ranges

Tests should include the following permutations:

RDATEs only
RRULEs only
RDATEs and RRULEs
RDATEs & EXDATEs only
RRULEs & EXDATEs only
RDATEs & EXRULEs only
RRULEs & EXRULEs only
RDATEs, EXDATEs & EXRULEs
RRULEs, EXDATEs & EXRULEs
RDATEs, RRULEs & EXDATEs
RDATEs, RRULEs & EXRULEs
RDATEs, RRULEs, EXDATEs & EXRULEs
)

Was able to send everyone a standard repeating.

Vendors REPLIED with no problem.

Was able to send a resch on time of the whole repeating meeting

Was able to send a reschedule on dates of one instance, thisandprior, thisandfuture instances. One vendor replied with no problem, but we receive error when open the accepted notice

Was able to send a confirm to a single meeting with comments.

Was able to send a cancellation to everyone.

Was able to send a weekly repeating meeting (every other week for 7 weeks). Vendors replied with no problem